"XPNET 3.0 Interim Bug Fixes (IBFs) and Enhancements - XN10JMS" Scr# Change Description ----- ------------------ SCR #3167 XNLIBN.XNLIB - rel3_ver1_xnlib_rel14_040624 19-FEB-04 XNLIBN.XNLIBN - rel3_ver1_xnlib_rel14_040624 XNLIBN.XNLIBR - rel3_ver1_xnlib_rel14_040624 XNLIBN.XNLIBEN - rel3_ver1_xnlib_rel14_040624 XNLIBN.XNLIBER - rel3_ver1_xnlib_rel14_040624 MHDR - rel3_ver1_mdhr06_040624 NLIB - rel3_ver1_nlib08_040624 OSSTCJ4 - last modified 26JUL2004 11:25,eof 28672 OSSTCJ4E - last modified 26JUL2004 11:24,eof 3812 ---OSS WAX 1.1 (to be installed on XPNET subvolume) PXSY31 - last modified 03SEP2004 12:33, eof 260608 sysaci/sysweb/sate.o (ver 08) T0000D45_02MAR04_WAX11_SATE08 sysaci/sysweb/AciIntraprocess.jar (ver 02) 15588 Apr 27 16:53 PXSY31L - listing of above files last modified 03SEP2004 12:33, eof 970 PXSY323 - last modified 03SEP2004 13:15, eof 272896 sysaci/sysweb/sate.o (ver 08) T0000D45_02MAR04_WAX11_SATE08 sysaci/sysweb/AciIntraprocess.jar (ver 02) 15588 Apr 27 16:53 PXSY323L - listing of above files last modified 03SEP2004 13:15, eof 970 ---OSS JMS 1.0 (to be installed on XPNET subvolume) PXJS10 - last modified 19APR2004 15:08, eof 2136576 sysaci/sysjms/lib/acijms.jar (ver 02) 133510 Mar 30 20:31 sysaci/sysutil/lib/xputil.a (ver 01) 123776 Apr 16 14:49 sysaci/sysutil/lib/xputil.jar (ver 02) 143958 Mar 30 19:13 sysaci/sysutil/javadoc/* (ver 02) Apr 19 11:01 PXJS10L - listing of above files last modified 19APR2004 15:09, eof 15873 Reference: Internal. Non Stop Java 4 (NSJ4) support. Several changes to various modules are needed to support NSJ4, all modules must be installed as a unit. NSJ1 note: Support for NSJ1 has been dropped. NSJ2 and NSJ3 notes: NSJ2 and NSJ3 continue to be supported without change. The XONCONF -JavaVmArgs param is required for NSJ2 and NSJ3, the syntax remains unchanged. The Satellite Engine is now built by executing make2.go or make3.go depending on the NSJ version required. The ".vars" file is obsolete, its' contents have been moved into the appropriate make.go file. If the ".vars" file was modified in the past, apply those changes to the appropriate make.go file. Existing Satellite Engine objects need not be rebuilt, but the make files should be modified, if necessary, for future builds. See the Implementation instructions for more. NSJ4 notes: NSJ4 WebApps (Satellite Engine) require the new XNCONF "-JavaVmArgs2" param. See file OSSTCJ4E and item #4 in the "Change" section below for details. Other configuration for NSJ4 applications remains the same as NSJ2 and NSJ3 (with typical changes needed to point to the correct version of java). Any NSJ4 application requiring XNLIB must use the library file named XNLIBEN. This is a new version of XNLIB built for IEEE_FLOAT support. NSJ2 and NSJ3 applications must not use XNLIBEN, they continue to use XNLIBN with TANDEM_FLOAT as in the past. The Satellite Engine for NSJ4 is built by executing make4.go. If customization is needed, edit the make4.go file and modify the appropriate variables. For example, CUSTLIB_DIRS may need to be modified to include native libraries. See the Implementation instructions for more. NOTE- Custom native libraries linked into a NSJ4 JVM must be built with IEEE_FLOAT support if such libraries pass floating point parameters. See the H.P. softdoc for NSJ4 (T3266) for details. Symptom: 1) A JVM that uses NETLIB (XNLIB) to run as a Satellite of XPNET traps for no apparent reason. Impacted applications include the Satellite Engine, JMS JVM's for the Java Device Handler and MobiPay, and the USEC JVM. 2) A JVM that uses XNLIB fails at startup with process create error 66. Impacted applications include the Satellite Engine, JMS JVM's for the Java Device Handler and MobiPay, and the USEC JVM. 3) None. Impacted applications include the Satellite Engine, JMS JVM's for the Java Device Handler and MobiPay, and the USEC JVM. 4) The Satellite Engine terminates saying "Servlet Engine is abnormally terminating (caller 180)" when using NSJ4 or newer. 5) The Satellite Engine logs "java.io.IOException: Stream closed" at java.io.BufferedInputStream ensureOpen(BufferedInputStream.java:) and stops processing. 6) Calls to getLocalHost fail if file /etc/hosts does not exist or the Tandem "Host Name" is not configured in SCF. Response time can also be intermittently delayed when getLocalHost is called. Problem: 1) Signal handling is not allowed with NSJ4. 2) NSJ4 JVM's are built as IEEE_float, so any library used must also be build as IEEE_float. 3) NSJ4 requires IEEE_float, the POW_ routine used by MHDR uses floating point. If we don't change this, the MHDR routines may need to be compiled with IEEE_float creating software management issues. 4) The JNI_GetDefaultJavaVMInitArgs call fails with jstatus of -1 when using NSJ4. That A.P.I. is no longer supported beginning with NSJ4. 5) The Tomcat thread that calls accept on the server socket was not dispatched in time to accept an incoming "connection" (request). This problem did not surface before NSJ4, the possibility of it happening prior to that exists but seems unlikely. 6) Changes in NSJ4 cause getLocalHost problems that did not occur with NSJ3 or earlier. The getLocalHost call also seems to be the underlying cause of the Thread timing problem in #5 above, that problem rarely or never occurred once the getLocalHost call was removed. Change: 1) Added entry point NETLIB_INIT_DONT_HANDLE_TRAPS to the NETLIB module of XNLIB. When this entry point is called, trap handling (signal handling) is not enabled as with NETLIB_INIT. Modified the Satellite Engine (sate.o) and the Netlib Java Native code (xputil.jar) to call the new entry point when NSJ4 or newer is used. The new sate.o and xputil.jar may be used for NSJ2, NSJ3, and NSJ4. When NSJ2 or NSJ3 are used, logic in these modules prevents NETLIB_INIT_DONT_HANDLE_TRAPS from being called, that method is only called when NSJ4 or newer is being used. NSJ2 and NSJ3 modules do not require the new XNLIBN released with this scr, however if it isn't used an undefined external for NETLIB_INIT_DONT_HANDLE_TRAPS will be detected (and can be ignored). 2) Built new XNLIB object files for use with NSJ4. XNLIBEN - Native user library, IEEE_float. XNLIBER - Native relinkable, IEEE_float. NSJ2 and NSJ3 continue to use XNLIBN and XNLIBNR which are built with TANDEM_float as in the past. 3) Renamed the POW_ routine to TEN_TO_POW and changed it so it no longer uses or returns floating point values. This is an internal MHDR (XNLIB) routine that should not be called by the user. Changed MHDR routines that used POW_ to use TEN_TO_POW instead. 4) Added code to support new syntax in the XNCONF for sending arguments to a NSJ4 JVM. The -JavaVmArgs2 argument is now supported and MUST be used for a NSJ4 (or newer) Satellite Engine. Each space separated word within -JavaVmArgs2 is passed unchanged to the JVM as one argument. The syntax for JVM arguments is the same as that specified when running a JVM from the OSH prompt. See file OSSTC4E for an example. The old -JavaVmArgs syntax must be used for NSJ2 and NSJ3. That syntax remains unchanged. Support for NSJ1 is dropped. 5) Changed AciIntraprocess.jar to call Thread.yield in threads that processes requests and responses Those threads are running while the listener thread needs cycles to accept the "next connection", calling Thread.yield should allow the listener thread to run. If an incoming "connection" is received, and the accept thread has still not received the required cycles, the thread that is attempting to complete the accept sleeps for short intervals waiting for accept to be called. 6) Changed AciIntraprocess.jar to call getByName instead of getLocalHost. Besides the call to getLocalHost above, such calls may be caused by application configuration files containing the word "localhost" (i.e. -jndihost localhost). If such configurations cause problems, one or all of the following TCP/IP configuration changes may be needed. If these hints and documentation in the softdoc do not help resolve the problem, contact H.P. support and refer to cases 040210-2304 and 040512-5957. a) If you have a HOSTS file in NSK space, an OSS link to it may be needed in the /etc directory. i.e. /etc/hosts -> /G/system/ztcpip/hosts b) If you have a RESCONF file in NSK space, an OSS link to it may be needed in the /etc directory. i.e. /etc/resolv.conf -> /G/system/ztcpip/recsonf c) The "Host Name" in SCF for the TCP/IP process may need to be configured. Implementation: - - XNLIB 3.1 - - Since XNLIB is run as a user library, do the following only after taking appropriate operator action. Restore the new XNLIB to a Guardian subvolume. Accelerate XNLIB using XNAXCL file. Application processes which bind in XNLIB must be re-compiled or re-bound with the new library. Application processes which use XNLIB as a library must be stopped and restarted in order for the new library to take effect. Take appropriate actions to avoid library conflict errors. - - WAX 1.1 (WebApps) - - If using NET24-XPNET Web Application Services, perform the following steps to complete the installation of this scr. The sample commands are to aid in the discussion, actual commands may vary from site to site and should be executed with caution. This scr and scr3196 are both included in the same version of sate.o (version 08), so scr3196 will also be installed by the following instructions. 1) Restore the PXSY* files mentioned above to the XPNET Guardian subvolume. If the XPNET subvolume is on a virtual disk, copy the PXSY* files to a temporary subvolume on a non-virtual disk and use those in step 2. Files on the current XPNET subvolume named OSSTCAT and OSSTCATE are obsolete and should be purged. These are sample configuration files for NSJ1 which is no longer supported. 2) Create a temporary OSS directory and use the OSS pax utility to restore the PXSY3 file to OSS. Restore the file applicable to the version of Tomcat your site is using (PXSY31 for Tomcat 3.1, PXSY323 for Tomcat 3.2.3). Example for a customer using Tomcat 3.2.3: > mkdir /user/temp > cd /user/temp /user/temp > pax -rvf /G//xpnet/pxsy323 # creates, overwrites /user/temp/sysaci/sysweb/* 3) Copy the following files from the temporary directory to the installation directory. These are files needed to make the executable sate object file. Makefile2, Makefile3, Makefile4, (new files) make2.go, make3.go, make4.go, (new files) sate.o (existing file) For example: > cp -p /user/temp/sysaci/sysweb/Make* \ /user/sysaci/sysweb/. > cp -p /user/temp/sysaci/sysweb/make* \ /user/sysaci/sysweb/. > cp -p /user/temp/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/. AciIntraprocess.jar will be installed in step 9. No changes were made to sysaci/sysweb/tomcat/*, so those files are not re-installed. 4) If needed, customize the make.go file for site specific variables (where = NSJ version). The ".vars" file is obsolete, if it was customized in the past apply those changes to the appropriate make.go file. The Satellite Engine for NSJ4 is built using make4.go. CUSTLIB_DIRS may need to be modified to include native libraries, if such libraries pass floating point parameters they must be built with IEEE_FLOAT support. See the H.P. softdoc for NSJ4 (T3266) for details. 5) The following files are obsolete and should be removed. You may want to copy them to some other directory until new sate objects are made, but they should be REMOVED from this directory to avoid confusion in the future. .vars, make.go, Makefile, Makefile16 Example, to remove the files: > cd /user/sysaci/sysweb > rm .vars > rm make.go > rm Makefile > rm Makefile16 6) Make the sate executable object file. NSJ2 and NSJ3 sate objects do not have to be re-linked, but it is highly recommended (because the make files have changed). They do, however, need to be stopped and started to install the new AciIntraprocess.jar mentioned in step 9. For example: > make4.go (builds an object file named sate) When making NSJ4 objects with make4.go, ignore warnings 10032 and 10034 (inconsistent floattype attributes). 7) Stop all satengine processes. 8) Copy the new sate object from step 6 to its runnable location. For example: > mv -i satengine old_sategine (rename old out) > mv -i sate satengine (rename new in) 9) Replace the installation version of the AciIntraprocess.jar file with the new version from the temporary installation directory (see step #2). For example: > cp -p \ /user/temp/sysaci/sysweb/AciIntraprocess.jar \ /user/sysaci/sysweb/. 10) Start satengine processes. 11) Purge temporary subvolumes and directories created in steps 1 and 2. - - JMS 1.0 - - If you have installed XPNET JMS prior to the date of this scr, and NSJ4 support is required for XPNET JMS, obtain an entire new release from A.C.I. and re-install it according to the "XPNET Java Message Service (JMS) Implementation Guide" (Publication No. XN-NT100-39). Dependencies: None. SCR #3211 ---OSS JMS 1.0 (to be installed on XPNET subvolume) 08-DEC-04 PXOJ071 - last modified 19APR2004 15:07, eof 8045056 PXOJ071L - last modified 19APR2004 15:08, eof 31076 listing of above files Reference: Internal Symptom: When restoring PXOJ071 with the PAX utility, messages like "pax: openjms-0.7.1/bin/admin.bat : Permission denied" display and the directory is not restored. Problem: The directory in the PAX file did not allow write access, so after creating it files could not be restored. Change: Changed directories so write access is allowed for owner and group (rwxrwxr-x). Implementation: Follow the normal instructions in the XPNET JMS Implementation Guide. Dependencies: None. SCR #3787 PXOJ071 01-MAY-2020 PXOJ071L Reference: Internal Symptom: We had inadvertently not been scanning the transitive dependency jars associated with the Open JMS functionality. When we added these to the Black Duck scans, it uncovered some license restrictions which prevented us from distributing this module. Problem: The license associated with the jdbc2_0-stdext.jar was mapped to the Sun Binary Code JDBC 2.0 License which restricts the usage to internal so it was unable to pass Legal review for distribution. Change: We had to remove the jdbc2_0-stdext.jar from the PXOJ071 pax file. Since this code appears to be a repackaging of code that is available in the JRE it should not be required as a separate package anyway. Implementation: Install the new PXOJ071 and PXOJ071L files and follow the instructions in the JMS Implementation Guide. Dependencies: None Code Review: CR-XPNET-100